Date: Fri, 17 Sep 93 04:30:01 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #273
To: packet-radio


Packet-Radio Digest         Fri, 17 Sep 93       Volume 93 : Issue  273

Today's Topics:
                 9600 baud - commercially available?
                         Digipeater (3 msgs)
                         HELP: PMP to HTX202
                         HF packet for IC720A
           I need info on getting started with packet radio
                             packet help
                       packet radio encryption
                      RACES packet terminal pgm

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 15 Sep 1993 11:31:18 GMT
From: dog.ee.lbl.gov!agate!howland.reston.ans.net!gatech!kd4nc!ke4zv!gary@network.ucsd.edu
Subject: 9600 baud - commercially available?
To: packet-radio@ucsd.edu

In article <2242@arrl.org> bbattles@arrl.org (Brian Battles WS1O) writes:
>In rec.radio.amateur.digital.misc, richgi@microsoft.com (Richard Gillmann)
>writes:
>>Can a 9600-baud packet station be set up entirely out of commercially
>>available items (not kits)? This would have to include a TNC, a 9600-baud
>>modem and a VHF or UHF radio.
>
>   Gracilis sells the PackeTwin system with a plug-in card for your
>IBM-compatible PC. It includes a 'DSY modem (9600 or 19,200 bit/s) and
>a TEK 440-MHz transceiver (2 W). Handy! (Mine was working fine into the local

Note, the Gracillis card does *not* include a WA4DSY (aka GRAPES) 56 kb
RF modem. It does include provisions for *driving* one externally through 
one of it's ports. 1200 baud, 2400 baud, 9600 baud, and 19.2 kb, daughter 
card modems are available for the card's other port. They're actuallly made 
for Gracillis by Kantronics.  The Tekk radio is small, originally intended
for board mounting. It is powered and driven off the daughtercard modem.

Gary
-- 
Gary Coffman KE4ZV          |"If 10% is good enough | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems | for Jesus, it's good  | uunet!rsiatl!ke4zv!gary
534 Shannon Way             | enough for Uncle Sam."| emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     | -Ray Stevens          | 

------------------------------

Date: Wed, 15 Sep 1993 11:23:42 GMT
From: dog.ee.lbl.gov!agate!doc.ic.ac.uk!uknet!icsbelf!mark@network.ucsd.edu
Subject: Digipeater
To: packet-radio@ucsd.edu

In article <01H2YIJ8KDDE91XURZ@delphi.com> WG0B@delphi.COM writes:
>ON 13 Sep 93 14:30:39 GMT
>FROM: ogicse!emory!kd4nc!ke4zv!gary@network.ucsd.edu
> 
>In response to:
>>    How a digipeater work ? Is it same as a repeater ?
> 
>You wrote:
>> A digipeater is a store and forward relay node......
> 
>If you would substitute "network node" (netrom node) in each instance
>where you used "digipeater", your answer would be reasonably accurate.
>It's no wonder newcomers are confused when even the "experts" don't know
>to use the correct terminology.

I think Gary was right...

 
>Digipeating is an instantaneous retransmission mode available
>(unfortunately) as a "feature" on virtually all TNCs.  

No TNC I know of "Instantaneously" retransmits what it hears. They all listen
to the the entire frame, STORE it (of course), mangle the header appropriately,
and then queue it for transmission. Most software can be configured to give
digi'd frames a "higher priority", ie they get sent sooner than ordinary frames.


>Digipeaters
>do *NOT* store and forward; they do *NOT* test the frequency prior to
>transmitting; and only at the destination station is the packet frame
>tested for accuracy.

They DO store and forward, and they DO check the frequency (by default anyway).
Not that on most TNC's you can disable the frequency checking. BAD idea!

What you are describing is the output from a modem attached (usually via
some more hardware) to the input of another modem.

If your description was right, then every TNC with digipeating enabled would
retransmit *everything* it heard. Can you imagine what the effect would be?


>Digipeating, as a mode, can be supported by most
>netrom compatible nodes.  Fortunately, it can also be disabled, as it
>should be in virtually all cases.

Sure, but not in the 'instantaneous' way you describe.

A Network Node (ie netrom, or netwrong as many would have it) does a 
completely different thing. It takes layer 2 frames from the user and (often)
packages them into layer 4 frames to send to other netrom nodes. The remote
node does the opposite. Netrom nodes support digipeating too (STORE AND FORWARD)
but lots of 'em have it turned off.

-Mark
-- 
Mark Willis                   Internet:  mark@icsbelf.co.uk
ICS Computing Group Ltd.      Packet:    GI0PEZ@GB7TED.#63.GBR.EU 
Belfast                       AmprNet:   44.131.15.3
Northern Ireland                         

------------------------------

Date: Wed, 15 Sep 1993 16:31:35 GMT
From: sdd.hp.com!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!jvp@network.ucsd.edu
Subject: Digipeater
To: packet-radio@ucsd.edu

In <01H2YIJ8KDDE91XURZ@delphi.com> WG0B@delphi.COM writes:

>ON 13 Sep 93 14:30:39 GMT
>FROM: ogicse!emory!kd4nc!ke4zv!gary@network.ucsd.edu
> 
>In response to:
>>    How a digipeater work ? Is it same as a repeater ?
> 
>You wrote:
>> A digipeater is a store and forward relay node......
> 
>If you would substitute "network node" (netrom node) in each instance
>where you used "digipeater", your answer would be reasonably accurate.
>It's no wonder newcomers are confused when even the "experts" don't know
>to use the correct terminology.
                                                     ^^^^^^^^
And you're one of these experts?

>Digipeating is an instantaneous retransmission mode available
>(unfortunately) as a "feature" on virtually all TNCs.

  Wrong. Digipeating is not instantaneous.

>Digipeaters do *NOT* store and forward

  Wrong. Digipeaters *DO* store and forward.

>they do *NOT* test the frequency prior to transmitting

  Wrong. Digipeaters *DO* test the freq prior to retransmitting

>and only at the destination station is the packet frame
>tested for accuracy.

  Right. Only the destination station does a CRC check and ack's the frame.

>Digipeating, as a mode, can be supported by most
>netrom compatible nodes.  Fortunately, it can also be disabled, as it
>should be in virtually all cases.

  Not necessarily. There's a lot less overhead by simple digipeating.
The distinction between digipeater and node is in the acknowledgement
packets, and path finding. A digipeater simply passes the frame on
to the next digipeater or the destination. The destination station is
responsible for sending an acknowledge packet back, which gets digipeated
back to the source station. Nodes give a local acknowledgement of the
packet when they receive it. That way, the destination has to only send
the acknowledgement back to the last node. There's a lot less chance of
a lost packet slowing you down.

  But in a clear channel, digipeating is more efficient if you only go
one or two hops. If the chance of packet loss is very low, this is more
efficient because the message bounces straight through to the destination,
without having to wait for a local CRC check and acknowledgement. I have
seen many cases where simple digipeating has a higher throughput than a node.
The there are also cases where a node has higher thoughput. It depends on
your environment.

--
+-----------------------------------------------------------------+
| Jim Van Peursem - Dept of EE and CprE - Iowa State University   |
| Ames, IA 50011 - internet: jvp@iastate or tools1.ee.iastate.edu |
+-----------------------------------------------------------------+

------------------------------

Date: Wed, 15 Sep 1993 11:44:39 GMT
From: haven.umd.edu!darwin.sura.net!gatech!wa4mei!ke4zv!gary@ames.arpa
Subject: Digipeater
To: packet-radio@ucsd.edu

In article <01H2YIJ8KDDE91XURZ@delphi.com> WG0B@delphi.COM writes:
>ON 13 Sep 93 14:30:39 GMT
>FROM: ogicse!emory!kd4nc!ke4zv!gary@network.ucsd.edu
> 
>In response to:
>>    How a digipeater work ? Is it same as a repeater ?
> 
>You wrote:
>> A digipeater is a store and forward relay node......
> 
>If you would substitute "network node" (netrom node) in each instance
>where you used "digipeater", your answer would be reasonably accurate.
>It's no wonder newcomers are confused when even the "experts" don't know
>to use the correct terminology.

Out of the horse's mouth. :-)
 
>Digipeating is an instantaneous retransmission mode available
>(unfortunately) as a "feature" on virtually all TNCs.  Digipeaters
>do *NOT* store and forward; they do *NOT* test the frequency prior to
>transmitting; and only at the destination station is the packet frame
>tested for accuracy.  Digipeating, as a mode, can be supported by most
>netrom compatible nodes.  Fortunately, it can also be disabled, as it
>should be in virtually all cases.

Unfortunately it's *you* who is confused. Digipeating *is* store and
forward. The frame is not relayed until it has been completely 
received, checksummed, and the header inspected to see if the frame
is requesting relay by the digipeater. The digipeater then obeys
channel access protocol and waits until the channel is free, within
the limits of hidden terminal syndrome, before retransmitting the
frame.

A Netrom node behaves somewhat similarly, except that it transmits
an immediate acknowledgement to the originating station before
retransmitting the frame now encapsulated in a Netrom frame. Netrom
offers automatic routing rather than depending on the source routing
of digipeaters by establishing a circuit table internally. What
netrom does *not* offer is end to end acknowledgement that a frame
actually reaches destination. It only acknowledges that *it* received
the frame from the orignating station. It will teardown the connection
after a time if it fails to deliver frames, but that gives little 
information to the originating station about the status of the transfer.

Netrom is useful, thanks to it's auto routing and hop by hop acknowledgement
internally, but it's not fundamentally different from the operation of
a digipeater in that it too is a store and forward node.

Gary

-- 
Gary Coffman KE4ZV          |"If 10% is good enough | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems | for Jesus, it's good  | uunet!rsiatl!ke4zv!gary
534 Shannon Way             | enough for Uncle Sam."| emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     | -Ray Stevens          | 

------------------------------

Date: Wed, 15 Sep 1993 21:02:47 GMT
From: gsm001!gsm001.mendelson.com!gsmlrn@uunet.uu.net
Subject: HELP: PMP to HTX202
To: packet-radio@ucsd.edu

In article <"15-Sep-93.8:52:46".*.David_Mensing.Roch817@Xerox.com> mensing.roch817@xerox.com writes:
>I am looking for someone who has had experience with connecting a Poor Man`s Packet
>modem to a Radio Shack HTX202 2 meter HT.
>
>I have been using this PMP modem with an ICOM 02AT for over a year without any
>problems. When I try using the HTX202 with this same PMP modem, it won`t key the
>radio. I know that the mic plugs are the same because I use the same speaker mic on
>both rigs. By the way, I can receive packets with the HTX202.

I had a similar problem with an mfj tnc. I called mfj and was told to
use a 3.3k, or if that did not work a 2.2k, resistor instead of the 48k
or so one used for Icom. 

If I remember correctly it goes between ptt and the radio's audio in.
BTW this cable also works fine with an Icom ic-2sat.

73,

Geoff.

-- 
Geoffrey S. Mendelson N3OWJ
(215) 242-8712   
gsm@mendelson.com     or uunet!gsm001!gsm

------------------------------

Date: Wed, 15 Sep 1993 13:37:32 UTC
From: pipex!sunic!trane.uninett.no!news.eunet.no!nuug!news.eunet.fi!anon.penet.fi@uunet.uu.net
Subject: HF packet for IC720A
To: packet-radio@ucsd.edu

I have a MFJ1270B with an add on tuner that I am trying to hookup
to my Icom 720A for HF packet operation. The problem I am having
is that I can not seem to drive the audio circuits of the 720.
The radio PTT is keyed and the radio goes into transmit but no
audio is present, FYI receive works fine. Has anyone encoutered
this type of problem and can tell me what to do I would be very
greatful. Please post the resonse to my email account
(scottm@csg.mot.com)
thanks




-------------------------------------------------------------------------
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin@anon.penet.fi.

------------------------------

Date: Mon, 6 Sep 1993 20:40:53 GMT
From: boulder!cnsnews!spot.Colorado.EDU!koberg@uunet.uu.net
Subject: I need info on getting started with packet radio
To: packet-radio@ucsd.edu

I'm interested in learning all about what Packet Radio is, what I
need to get started, perhaps how to build my own stuff, what
software is available, etc.

In other words, everything and anything that's out there, information
wise.

Respond via e-mail to koberg@spot.colorado.edu

Thanks mucho.

------------------------------

Date: Wed, 15 Sep 93 17:10:44 GMT
From: pipex!uknet!mcsun!sun4nl!hacktic!utopia.hacktic.nl!consolat.hacktic.nl!zerial.hacktic.nl!zerial@uunet.uu.net
Subject: packet help
To: packet-radio@ucsd.edu

> You might get more response if you mention your email address.  Many
> of us read the news posts as digests from ucsd.edu and a lot of the
> message header is deleted to save space.  The "From:" line on your
> message is about 80 chars of site!site!site!site...
> 
Ah yes, I forgot! My mail adress is zerial@zerial.hacktic.nl
And as far as my from line's concerned, I have NO idea how
it got to be that long.. I'll sure ask somebody though.
(my boss)

                Hope to find some reply's soon,

                Zerial..

------------------------------

Date: 17 Sep 93 10:11:39 GMT
From: news-mail-gateway@ucsd.edu
Subject: packet radio encryption
To: packet-radio@ucsd.edu

<g4wrw@g4wrw.ampr.org> Dave, G4WRW wrote:


>In the first category comes things like the scramblers used on G3RUH/K9NG
>modems (and others no doubt), using PKZIP to compress a file so it takes
>less bandwidth, 7plus and UUcode etc. The fact that most of these make it
>difficult for someone else to read the contents is purely coincidental......

Well, Radio Eriwan's response would be: in principle/theory yes,
but ... the files which really cause trouble are of Jumbo size.
In order to squeeze them through HF links and to circumvent size
limitations they are split up into many smaller chunks.
It is not uncommon in the German PR network that the check list of a BBS
is flooded by some 40..70 split files used for dissemination of a single
400K SFX thing which won't sfx until all have been recorded intact.
Before that, everything received can be accounted to as noise.
Can you think of a more effective encryption than just omitting or
holding back one of these 40 parts of a large ZIPped file?
In other words, transparency is lost completely with compressed and split
files, unless a sysop reconstructs them and checks them for integrity
b e f o r e  he forwards any part further. This would also make any
manipulation impossible.

An important question is, whether it is fair and feasible to put this
additional work load onto the shoulders of sysops and whether they are
prepared to do it.

Similar considerations as with split files apply to correction mechanisms.
A working FEC, when applied to an encoder/decoder, is transparent if and
only if the original data content can be regenerated immediately for one
hop, i.e. in a direct digipeater-to-digipeater or BBS-to-BBS configuration.
All long-loop applications seem vulnerable to manipulation and are also
inefficient from a systematic point of view, because they very often make
it difficult, if not practically impossible to locate the point of failure.

And then there are gimmicks like 7plus. From its first to the present
version 2.1, after more than 2 years unlike advertised, 7plus is not
capable to detect all single bit errors let alone to correct them,
despite of the publication of the underlying design error in July 91.
This is an invitation to amateur cryptographers to manipulate the two
weak bits per line to produce 2^(lines*2) permutations which remain
undetected when decoding. A professional cryptanalist would probably have
little difficulty to break this code, but at radio amateur level the
type of encryption is cumbersome to crack, although probably caused by
mere incompetence. In any case, even involuntary encryption is illegal.

I hope that I could contribute some technical arguments in favor of Jim,
4X1RU, to keep his important links clean from any 7plus and other
intransparent binary or encoded files.


Dietmar DJ4RX @ LX0PAC.LUX.EURO


If you want to answer directly, please use the packet radio address above.

p.s. I leave it as a quiz for those interested
     to find out the displacements of the two foul bits.

------------------------------

Date: Thu, 16 Sep 93 09:17:46 GMT
From: news!dg-rtp!webo!dg-webo.webo.dg.com!abracket@uunet.uu.net
Subject: RACES packet terminal pgm
To: packet-radio@ucsd.edu

In article <11SEP199315300152@bioch.tamu.edu> mwhitsitt@tamu.edu writes:
>A while back, there was some mention of a packet terminal program specifically 
>for use in RACES applications.  I never saw any more about it's availability an 
>such.  Any information would be appreciated.
>
	Mabye if someone has it they could post the information...
Thanks
--
73-al
--

 Did I drop my .sig in the coffee???		Al Brackett
 N1IQQ @ KA1RCI.RI (for those that know)  	abracket@dg-webo.webo.dg.com
  Work For Peace / Plan For Conflict  /  You can't WIN if You don't TRY
 [insert] Standard Disclamer Here<   > 	BLESS / PEACE

------------------------------

End of Packet-Radio Digest V93 #273
******************************
